In many cases, data packets need to be sent over a communication network between a user equipment and another entity. Transmissions can be performed both in downlink and uplink direction and the other entity is often another user equipment, e.g. in a telephone call. The other entity may also be service entity like a server which may send different packet flows for sound and video to the user equipment, e.g. in a streaming session, while the user equipment may send data to the service entity to initiate the streaming session by control signaling. The other entity may either be part of the communication network or it is able to exchange data packets with the network.
The communication network can be a fixed or a mobile network. More than one network can be involved in the transmission, e.g. if the user equipment is located in a mobile network which is interfacing directly or via intermediate networks to a fixed network in which the other entity is located. Customary mobile networks comprise a core network with core network nodes, e.g. a serving general packet radio service support node (SGSN) or a gateway general packet radio service support node (GGSN). The core network nodes allow the exchange of data with external networks such as the Internet or mobile or fixed networks of other operators. Furthermore, customary mobile networks comprise one or more access networks with access network nodes for controlling the radio transmission to user equipment, commonly designated, e.g., as base station controllers, radio network controllers (RNC), Node B or base transceiver stations. Other implementations of the nodes and networks have been proposed, for example an enhanced GSN and an enhanced RNC which perform different parts of the SGSN functionality and thus allow omitting an SGSN.
Depending on the type of packet traffic, the requirements for the transmission differ significantly. For example, voice transmission requires low delay and jitter while a limited amount of errors can be acceptable. Streaming sessions using packet buffers typically allow higher delays and jitter and the receiver can generally also correct or hide errors. File transfer can often be performed as best-effort traffic but normally requires error-free data. In addition, operators may choose to offer different qualities of service (QoS) depending on the user subscription, i.e. they may choose to perform user differentiation. Accordingly, the provision of a defined quality of service is an important concept in the control of data traffic as described for example in technical specification 3GPP 23.107 V 6.3.0. of the 3rd Generation Partnership Project “Quality of Service (QoS) concept and architecture”.
Different contexts define the quality of service relating to a data transmission involving nodes of a communication network and the user equipment. The user equipment and a core network node negotiate a PDP (Packet Data Protocol) context which specifies parameters for the transmission of data packets to and from the user equipment. In addition, further contexts are set up for different links between the service entity and the user equipment, e.g. a radio bearer between an access node and a user equipment, which specifies the transmission parameters on the radio link. Packet flows between the service entity and the user equipment are then mapped to these contexts and forwarded accordingly.
Current 3GPP standards define a mechanism to map downlink data to a packet bearer. For this purpose, the bearer is associated with a PDP context. The PDP context is the granularity with which QoS can be provided, i.e. different PDP contexts can provide a different QoS. The mapping of packets onto PDP contexts is done in an edge node of the communication network, e.g. in the GGSN using downlink Traffic Flow Templates (TFT). A TFT is a packet filter which defines rules that uniquely map incoming data packets onto a PDP context. The downlink TFT is part of the PDP context definition and can be configured to operate on a number of different parameters. For example, the IP source address of a data packet or the “Type of Service”-field (ToS) in the IP-header can be used to map packets onto a PDP context. The Session Management (SM) protocol is used to manage PDP Contexts.
In the uplink, the user equipment requires information how to map data packets from an application to a bearer or to the associated context. However, this is not in the scope of the current 3GPP standards. This functionality is defined proprietarily and can differ between vendors of user equipment. In one implementation, the user equipment has several PDP context templates, each with a different associated QoS. A connection manager provides a mapping for each application to one of the PDP context templates. This mapping is a static configuration which creates a binding in the connection manager and which is signaled to the user equipment, e.g. by an SMS. Typically, the user performs the configuration by visiting the web-site of an operator and entering the phone model he is using and which application he wants to configure, e.g. WAP or MMS. Upon initiation of a session, e.g., when making a call, the application communicates to the connection manager through a proprietary API (Application Programming Interface). The connection manager associates the data packets from the application with the configured PDP context and, if required, sets up the context. Correspondingly, there is a static binding between application and PDP context template. The identifiers and formats used in the configuration are specific for each vendor.
As a result, the existing methods for associating data packets with a bearer are inflexible and do not allow dynamic changes of the configuration. A further problem is that application development is both access specific and vendor specific, i.e. applications must be written for a specific access (e.g. 3GPP) and a particular vendor of user equipment because the QoS API in the above binding mechanism may differ for both vendor and access.
Furthermore, user equipment according to 3GPP specifications may consist of two entities, a terminal equipment (TE) and a mobile terminal (MT) which are logically and optionally also physically distinct. Applications are executed in the terminal equipment and data packets are exchanged over the mobile terminal with the mobile network. In the state of the art, an interface between TE and MT would be required over which it is possible to convey the bearer requirements of the application. As the binding of application and context is vendor specific in present user equipment, different interfaces would be required. If the terminal equipment is for example a personal computer and the terminal a mobile network card, the computer may need to support different interfaces for different card vendors, leading to high complexity and cost.
For transmissions in an IP network, the differentiated services concept has been proposed. The differentiated services concept is described for example in the Request for Comments 2474 “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers” of the Internet Engineering Task Force. The concept designates a data field in the header of a data packet in different versions of the Internet Protocol (IP). The value of the data field specifies which quality of service should be used when handling the packet. This value is commonly designated as Differentiated Services Code Point (DSCP).